Matching refunds to payment instruments employed in a proxy card transaction

ABSTRACT

Matching refunds to the appropriate payment instrument employed in a proxy card transaction comprises receiving a first payment authorization request for a transaction between a merchant and a user, the payment authorization request comprising an identification of an account of the user and an identifier for the transaction, the user account having associated therewith a plurality of payment instruments available for conducting payment transactions; determining a particular payment instrument with which to conduct the transaction; associating the transaction identifier with the particular payment instruments utilized in the transaction; receiving a first refund instruction to refund all or a portion of a payment amount of the transaction, the first refund instruction comprising the transaction identifier; determining the particular payment instrument associated with the transaction identifier provided in the first refund instruction; and initiating the refund to the particular payment instrument determined to be associated with the transaction identifier.

CROSS-REFERENCE TO RELATED APPLICATIONS

This patent application claims priority to U.S. Provisional PatentApplication No. 61/678,089, filed Jul. 31, 2012 and entitled “Proxy CardSystem.” The entire disclosure of the above-identified priorityapplication is hereby fully incorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates generally to proxy card transactions, andmore particularly to matching refunds to the appropriate paymentinstrument employed in a proxy card transaction.

BACKGROUND

In a conventional merchant-consumer financial transaction, themerchant's point of sale terminal or online payment process enginesubmits a payment request to an acquirer for payment for thetransaction. The acquirer then submits the request to authorize thetransaction to an issuer through a card network. If funds are available,the issuer sends an authorization code to the acquirer through the cardnetwork, and the acquirer notifies the merchant of the approval for thepayment transaction. The payment process involves a single paymentrequest generated and submitted by the merchant.

Conventional merchant-consumer financial transactions also have involvedpayment via a consumer's financial account, such as a debit card, creditcard, or stored value card. The consumer card typically accesses onlyone type of account, which is maintained by only one issuer. Forinstance, an “issuer1” credit card accesses only the consumer'sfinancial account from “issuer1,” and payment is approved/denied by asingle issuer (“issuer1”). Approval or denial of the transaction isdependent upon rules set by the particular issuer, for example, creditlimits and geographical limitations. Notification of a violation ofthese rules results in a declined transaction, and the consumer mustcontact the issuer to alter the rules or to address a declinedtransaction.

In a conventional payment instrument transaction, the merchant suppliesthe transaction identification (“ID”) to a payment instrument system.The payment instrument system can use the transaction ID to record thetransaction for later access. For example, the payment instrument systemcan use the transaction ID to identify the transaction for a refund or achargeback.

In a conventional payment instrument system, a refund may be initiatedby a merchant with or without the request of the user. The merchant mayprovide a refund authorization including the transaction ID to thepayment instrument system to refund the account of the user for all or apart of the transaction amount from the original transaction. Thepayment instrument system identifies the user account associated withthe transaction ID and issues the refund to the corresponding useraccount.

In a conventional payment instrument system, a chargeback may beinitiated by the payment instrument system. For example, a user mayindicate to a payment instrument system that a charge was in error andrequest a chargeback to the merchant for a particular transaction. Thepayment instrument system can identify the transaction ID associatedwith the particular transaction, identify the merchant associated withthe particular transaction, and provide the chargeback and thetransaction ID to the merchant to initiate a refund.

SUMMARY

One aspect of the example embodiments described herein provides acomputer-implemented method to match refunds to the appropriate paymentinstrument employed in a proxy card transaction. A payment systememploys a server configured for receiving, using one or more computingdevices, a first payment authorization request for a transaction betweena merchant and a user, the payment authorization request comprising anidentification of an account of the user and an identifier for thetransaction, the user account having associated therewith a plurality ofpayment instruments available for conducting payment transactions;determining a particular payment instrument of the plurality of paymentinstruments with which to conduct the transaction; associating thetransaction identifier with the particular one of the paymentinstruments utilized in the transaction; communicating a second paymentauthorization request to a computing system associated with an issuer ofthe particular payment instrument, requesting authorization to fund thetransaction using the particular payment instrument; receiving a firstpayment authorization from the computing system associated with theissuer of the particular payment instrument, authorizing funding of thetransaction using the particular payment instrument; communicating asecond payment authorization authorizing funding of the first paymentauthorization request based at least in part on the first paymentauthorization; receiving a first refund instruction to refund all or aportion of a payment amount of the transaction, the first refundinstruction comprising the transaction identifier; determining theparticular payment instrument associated with the transaction identifierprovided in the first refund instruction; and initiating the refund tothe particular payment instrument determined to be associated with thetransaction identifier.

Another aspect of the example embodiments described herein provides acomputer program product that is installed on a server to match refundsand chargebacks to the appropriate payment instrument employed in aproxy card transaction. The computer program product includes anon-transitory computer-readable storage device having computer-readableprogram instructions stored therein. The computer-readable programinstructions include computer program instructions to receive a firstpayment authorization request for a transaction between a merchant and auser, the payment authorization request comprising an identification ofan account of the user and an identifier for the transaction, the useraccount having associated therewith a plurality of payment instrumentsavailable for conducting payment transactions; determine a particularpayment instrument of the plurality of payment instruments with which toconduct the transaction; associate the transaction identifier with theparticular one of the payment instruments utilized in the transaction;communicate a second payment authorization request to a computing systemassociated with an issuer of the particular payment instrument,requesting authorization to fund the transaction using the particularpayment instrument; receive a first payment authorization from thecomputing system associated with the issuer of the particular paymentinstrument, authorizing funding of the transaction using the particularpayment instrument; communicate a second payment authorizationauthorizing funding of the first payment authorization request based atleast in part on the first payment authorization; receive a first refundinstruction to refund all or a portion of a payment amount of thetransaction, the first refund instruction comprising the transactionidentifier; determine the particular payment instrument associated withthe transaction identifier provided in the first refund instruction; andinitiate the refund to the particular payment instrument determined tobe associated with the transaction identifier.

These and other aspects, objects, features and advantages of the exampleembodiments will become apparent to those having ordinary skill in theart upon consideration of the following detailed description ofillustrated example embodiments, which include the best mode of carryingout the invention as presently presented.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting a system for matching refunds to theappropriate payment instrument employed in a proxy card transaction, inaccordance with certain example embodiments.

FIG. 2 is a block flow diagram depicting a method to register a userproxy card, in accordance with certain example embodiments.

FIG. 3 is a block flow diagram depicting a method for associating atransaction identification with a payment instrument, in accordance withcertain example embodiments.

FIG. 4 is a block flow diagram depicting method for matching refunds tothe appropriate payment instrument employed in a proxy card transaction,in accordance with certain example embodiments.

FIG. 5 is a block flow diagram depicting a computing machine and amodule, in accordance with certain example embodiments.

DETAILED DESCRIPTION OF THE EXAMPLE EMBODIMENTS Overview

In one example embodiment, proxy card payment systems enable users toutilize a single card to access multiple financial accounts maintainedby multiple issuers. The user receives a proxy card from the proxy cardsystem and either creates a new proxy card system account or associatesthe proxy card with the user's digital wallet account already maintainedby the proxy card system.

The user then associates one or more financial card accounts with theproxy account. For example, the user can associate with the user's proxycard account multiple debit/credit cards maintained by multiple issuers(including the proxy card system operating as an issuer), stored valuecards (for example, gift cards, prepaid cards, re-loadable transactioncards, exchange cards, and other forms of non-credit based value cards),loyalty cards or store rewards cards, value added service accounts (forexample, coupons, vouchers for prepaid offers, redemption offers, andother forms of offers), peer-to-peer transaction accounts, bank accountsand/or other forms of financial card accounts.

The user applies the proxy card to a transaction with the merchant in amanner similar to the application of any financial card to atransaction. The merchant forwards the payment request to the acquirer,which forwards the payment request to the card network. The card networkforwards the proxy card payment request to the proxy card system, whichfunctions as the issuer for the payment request. The proxy card systemcan read proxy card account information from the payment request and canaccess the user's account associated with the proxy card. If the proxycard system is the issuer of the financial account, the proxy cardsystem will approve or decline the transaction. If another issuermaintains the financial account to be used for the transaction, theproxy card system will generate and send a new payment request to thatissuer via the card network.

The proxy card system will receive the authorization message from theissuer via the card network if the transaction is approved. The proxycard system forwards an authorization to the acquirer through the cardnetwork, which forwards the authorization to the merchant. The merchantthen approves the transaction.

In conventional transactions, the merchant system transmits atransaction identification (“ID”) to the issuer of the paymentinstrument utilized by the user when conducting the transaction. Thetransaction ID can be used by the merchant and the payment instrumentissuer to store, locate, retrieve, or otherwise identify thetransaction.

As described previously, when conducting a transaction, the merchantsystem sends an initial transaction payment request to the proxy cardissuer. The initial proxy card payment request contains the transactionID. However, a second payment request is created by the proxy cardsystem and forwarded to the payment instrument system that issued thepayment instrument designated by the user as the backing instrument.

In a conventional proxy card payment system, the backing instrument usedfor one transaction may be different than the backing instrument usedfor another transaction. Additionally, the current rules for whichpayment instrument to use for a proxy card transaction may differ fromthe payment instrument rules used at the time of the transaction forwhich a refund is desired. When the conventional proxy card paymentsystem receives a refund request from a merchant, the proxy card systemis unable to direct a refund to the appropriate payment instrument, evenif the proxy card payment system recorded the transaction ID with theproxy card account.

At a time after the transaction, a refund authorization can be issued bythe merchant system to the proxy card system. However, the paymentinstrument that was designated by the user to be the backing instrumentfor transactions may have changed. The user may have instructed theproxy card system to change the default backing instrument. The rulescan be configured to allow multiple payment instruments to be thebacking instrument depending on the transaction details, merchantdetails, timing of the transaction, or any other rule established in theproxy card system. The proxy card system may be unable to determine withcertainty which payment instrument should receive the refund. Thus, theproxy card system has a need to determine the payment instrument thatwas employed in the transaction that is receiving the refund. Thecorrect payment instrument must be determined so that the refund can beapplied to the appropriate account of the user or transferred to thecorrect payment instrument system.

In an example embodiment, the proxy card system identifies thetransaction ID for new transaction requests that are received from amerchant. When the proxy card system determines from the rules whichpayment instrument will be used to process the transaction, the proxycard system can associate the transaction ID with the paymentinstrument. The proxy card system can store the transaction ID in adatabase of transaction IDs and associate an identification of thepayment instrument that is used for the identified transaction.Additionally or alternatively, the proxy card system can associate thetransaction ID and the employed payment instrument in a transactionrecord database of the proxy card system. Additionally or alternatively,the proxy card system can store the transaction ID and the employedpayment instrument in an account of the user on the proxy card system.The proxy card system can associate and store the transaction ID and theutilized payment instrument in any manner or location available to theproxy card system that will allow the transaction ID and the utilizedpayment instrument to be retrieved at the time of a refund or any othersuitable time.

In an example embodiment, at the time of receiving a refundauthorization, the proxy card system cross-references the transaction IDreceived in the refund authorization with the transaction IDs saved in adatabase. Once the proxy card system identifies the originaltransaction, it can determine the correct payment instrument used toprocess the original proxy card transaction. The proxy card systemtransmits a second refund authorization so that the refund is crediteddirectly to the payment instrument the user had selected at the time ofthe original proxy card purchase. In an example embodiment, the user isinformed of the refund success once the refund is processed successfullyby the proxy card system.

In an alternate embodiment, the proxy card system retains the refund inthe user account. The proxy card system can associate the refund withthe payment instrument used in the original transaction and apply therefund to future transactions using the payment instrument as thebacking instrument in a proxy card purchase. Alternatively, the proxycard system 140 can use the retained refund for any purchase involvingthe proxy card account of the user.

In an example embodiment, User A purchased merchandise two weeks agousing her proxy card. Her selected payment card was her payment cardissued by Bank X. The merchant transmits the proxy card payment request,which includes the transaction ID for the purchase, to the proxy cardsystem. The proxy card system receives the proxy card payment requestand the transaction ID. User A brings the merchandise back to themerchant, and the merchant refunds the purchase price back to the proxycard she used to make the purchase. The refund is forwarded to the proxycard system from the merchant system with the transaction ID for theoriginal proxy card transaction. The proxy card system correlates thetransaction ID with User A's payment card issued by Bank X, byretrieving the original proxy card transaction information from User A'saccount associated with the transaction ID and determining that User A'spayment card issued by Bank X was the card selected at the time thepurchase was made. The proxy card system passes the full refund to UserA's payment card issued by Bank X. In an example embodiment, the proxycard system can pass the refund to User A's payment card issued by BankX regardless of whether the payment card is active, deactivated,deleted, disabled, or partially disabled from User A's wallet account.

In an alternative example embodiment, the proxy card system can receivea chargeback request from the original backing payment instrumentsystem, and push the chargeback request to the original merchant ofrecord. That is, a user can report a transaction as fraudulent,containing incorrect pricing, or for any suitable reason request that achargeback be issued. If the chargeback is issued to the proxy cardsystem, the proxy card system can determine the merchant, transactionID, and payment instrument involved in the transaction and forward thechargeback to the merchant.

Example System Architectures

Turning now to the drawings, in which like numerals represent like (butnot necessarily identical) elements throughout the figures, exampleembodiments are described in detail.

FIG. 1 is a block diagram depicting a system for transmitting merchantcategory codes to a payment instrument, in accordance with certainexample embodiments. As depicted in FIG. 1, the system 100 includesnetwork devices 110, 130, 140, and 170 that are configured tocommunicate with one another via one or more networks 105.

Each network 105 includes a wired or wireless telecommunication means bywhich network devices (including devices 110, 130, 140 and 170) canexchange data. For example, each network 105 can include a local areanetwork (“LAN”), a wide area network (“WAN”), an intranet, an Internet,a mobile telephone network, or any combination thereof. Throughout thediscussion of example embodiments, it should be understood that theterms “data” and “information” are used interchangeably herein to referto text, images, audio, video, or any other form of information that canexist in a computer-based environment.

Each network device 110, 130, 140 and 170 includes a device having acommunication module capable of transmitting and receiving data over thenetwork 105. For example, each network device 110, 130, 140 and 170 caninclude a server, desktop computer, laptop computer, tablet computer, atelevision with one or more processors embedded therein and/or coupledthereto, smart phone, handheld computer, personal digital assistant(“PDA”), or any other wired or wireless, processor-driven device. In theexample embodiment depicted in FIG. 1, the network devices 110, 130, 140and 170 are operated by end-users or consumers, merchant operators,proxy card system operators, and payment instrument system operators,respectively.

The user 101 can use the communication application 112, such as a webbrowser application or a stand-alone application, to view, download,upload, or otherwise access documents or web pages via a distributednetwork 105. The network 105 includes a wired or wirelesstelecommunication system or device by which network devices (includingdevices 110, 130, 140 and 170) can exchange data. For example, thenetwork 105 can include a local area network (“LAN”), a wide areanetwork (“WAN”), an intranet, an Internet, storage area network (SAN),personal area network (PAN), a metropolitan area network (MAN), awireless local area network (WLAN), a virtual private network (VPN), acellular or other mobile communication network, Bluetooth, NFC, or anycombination thereof or any other appropriate architecture or system thatfacilitates the communication of signals, data, and/or messages.

The communication application 112 can interact with web servers or othercomputing devices connected to the network 105, including the point ofsale terminal 134 of the merchant system 130, the merchant server 135 ofthe merchant system 130, and the web server 141 of the proxy card system140.

The user network device 110 may include a digital wallet applicationmodule 111. The digital wallet application module 111 may encompass anyapplication, hardware, software, or process the user device 110 mayemploy to assist the user 101 in completing a purchase. The digitalwallet application module 111 can interact with the communicationapplication 112 or can be embodied as a companion application of thecommunication application 112. As a companion application, the digitalwallet application module 111 executes within the communicationapplication 112. That is, the digital wallet application module 111 maybe an application program embedded in the communication application 112.

The user device 110 can include a proxy card application 115. The proxycard application 115 can interact with the communication application 112or be embodied as a companion application of the communicationapplication 112 and execute within the communication application 112.The proxy card application 115 may further be embodied as a companionapplication of the digital wallet application module 111 and executewithin the digital wallet application module 111. The proxy cardapplication 115 may employ a software interface for configuration thatmay open in the digital wallet application module 111 or may open in theweb browser application 112. Alternatively, the proxy card application115 may be execute on the user device 110 independent of the digitalwallet application module 111 and the communication application 112.

The proxy card application 115 is operable to allow a user 101 toconfigure a proxy card account on the user device 110 and the proxy cardsystem 140. The proxy card application 115 can allow the user 101 to setrules, confirm transactions, select preferred cards for a transaction,receive notice of a card selection, and provide other suitable services.

The user device 110 also includes a data storage unit 113 accessible bythe digital wallet application module 111, the proxy card application115, and the communication application 112. The example data storageunit 113 can include one or more tangible computer-readable storagedevices. The data storage unit 113 can be stored on the user device 110or can be logically coupled to the user device 110. For example, thedata storage unit 113 can include on-board flash memory and/or one ormore removable memory cards or removable flash memory.

In an example embodiment, the proxy card looks and/or functions in thesame manner as a standard credit or debit card. For example, the proxycard may have the user's 101 name and/or account number listed on thefront of the card. An example proxy card can include a magnetic stripeencoding the proxy card system 140 account information of the user 101.In an example embodiment, the account information encoded in themagnetic stripe routes payment requests to the proxy card system 140 forprocessing.

In an alternative example embodiment, the proxy card is not a physicalcard. Instead, the proxy card is an account accessible by a wireless tapof a user device 110, an account identification number, a bar code or QRcode, a token, or other form of account identification or access, whichmay be entered manually into the term POS terminal 134 or which may becaptured by the POS terminal 134. The proxy card as discussed throughoutthe specification refers to a physical card as well as the proxyaccount.

The user 101 may use the user device 110 or other network device toregister the proxy card and/or access the proxy card system account ofthe user 101. The user device 110 may comprise appropriate technologythat includes or is coupled to a web server (for example, Google Chrome,Microsoft Internet Explorer, Netscape, Safari, Firefox, or othersuitable application for interacting with web page files).

The proxy card system 140 includes a data storage unit 147 accessible bythe web server 141. The example data storage unit 147 can include one ormore tangible computer-readable storage devices.

The user 101 can use a web server 141 on the proxy card system 140 toview, register, download, upload, or otherwise access the proxy cardsystem 140 via a website (not illustrated) and a communication network105). The user 101 associates one or more registered financial cardaccounts, including bank account debit cards, credit cards, gift cards,loyalty cards, coupons, offers, prepaid offers, store rewards cards, orother type of financial account that can be used to make a purchase orredeem value-added services with a payment account of the user 101. Theproxy card system 140 also may function as the issuer for the associatedfinancial payment instrument. The user's 101 registration information issaved in the proxy card system's 140 data storage unit 147 and isaccessible the by web server 141. The user 101 also may use the webserver 141 to define payment rules.

The merchant system 130 may use a web server 135 to view, download,upload, create offers, sell products online, or otherwise access theproxy card system 140 via a website 136 and a communication network 105.The merchant system 130 represents an entity that offers products forthe user 101 to purchase or use. The merchant system 130 includes apoint of sale (“POS”) terminal 134. The POS terminal 134 may be operatedby a salesperson that enters the purchase data into the POS terminal 134to complete the purchase transaction. The merchant system 130 may be aphysical location or an online merchant.

The user 101 may request a purchase from the merchant system 130. In anexample embodiment, the purchase is initiated by a wireless “tap” of themobile device 110 with the POS terminal 134. In an alternative exampleembodiment, the purchase is initiated when the user 101 enters anaccount identification number at the POS terminal 134 or in the mobiledevice 110. In another alternative example embodiment, the purchase isinitiated online with the merchant server 135. The purchase may beinitiated via the merchant website 136. In yet another alternativeexample embodiment, the purchase is initiated by use of apermanent/temporary virtual/physical token, QR code, bar code, or othersuitable machine-readable medium captured by the terminal reader 131.The merchant's POS terminal 134 interacts with an acquirer (for exampleChase PaymentTech, or other third party payment processing companies),the card network (for example VISA, MasterCard, American Express,Discover or other card processing networks), the proxy card system 140,and the issuer (for example Citibank, CapitalOne, Bank of America, andother financial institutions to authorize payment).

The payment instrument system 170 represents any the system that issuesor maintains a financial account that the can be associated with theproxy card system 140. Examples of the financial accounts that can beassociated include, but are not limited to, debit cards, credit cards,stored value cards, loyalty/rewards cards, bank accounts, peer-to-peertransaction accounts, stored value accounts, and coupons (includingpurchased offers and other offers). The payment instrument system 170can communicate with the proxy card system 140, the merchant system 130,and the user device 110 as needed to configure accounts, associatepayment instruments, supply instrument art, or perform any othersuitable functions.

The payment instrument system 170 includes a data storage unit 177accessible by the web server 171. The example data storage unit 177 caninclude one or more tangible computer-readable storage devices.

The user 101 and others can use a web server 171 on the paymentinstrument system 170 to view, register, download, upload, or otherwiseaccess the payment instrument system 170 via a website (not illustrated)and a communication network 105).

Example Processes

The components of the example operating environment 100 are describedhereinafter with reference to the example methods illustrated in FIG. 2.

FIG. 2 is a block flow diagram depicting a method 200 to register a userproxy card, in accordance with certain example embodiments.

With reference to FIGS. 1 and 2, in block 205, the proxy card system 140issues a proxy card account to the user 101. In an example embodiment,the user 101 requests a proxy card using a web server 141, and the proxycard is mailed to the user 101. The user 101 may be issued an accountnumber to be used for transactions via the Internet before or after aphysical card is received. In an alternative example embodiment, theproxy card system 140 mails an inactivated proxy card to the user 101.The proxy card is then activated by the user 101 before use. In analternative example embodiment, a physical proxy card is not issued. Theproxy card account information can be stored in the user device 110 andis used to make a payment via a NFC, Bluetooth, Wi-Fi, or other form ofwireless tap of the user device 110 with the point of sale (“POS”)terminal 134. In an alternative example embodiment, the purchase isinitiated when the user 101 enters an account identification number atthe POS terminal 134 or in the user device 110. The accountidentification number may be the proxy card account number or adifferent number that links the payment transaction to the proxy cardaccount. In yet another alternative example embodiment, a purchase isinitiated by use of a permanent/temporary virtual/physical token QRcode, bar code, or other suitable machine-readable medium that is readby the POS terminal 134. In these cases, the POS terminal 134 maycomprise a scanner, camera, or other reading device that captures theproxy account information, such as a bar code or QR reader or othersuitable reading device. The proxy account information may be printed inpaper or other form.

In block 210, the user 101 creates a new proxy card system 140 accountor links the proxy card to an existing account on the proxy card system140. The proxy card system 140 also may create or update an account on aproxy card application 115 on the user device 110 or on a digital walletapplication module 111 on the user device 110.

In block 215, the user 101 activates the proxy card and associates oneor more financial instrument accounts (for example, debit cards, creditcards, gift cards/stored value cards, loyalty cards/reward cards,peer-to-peer payment accounts, coupons, prepaid or other offers, andother accounts used to make a purchase or redeem value added services)with the proxy card account. In an example embodiment, the user 101associates multiple financial instrument accounts with the proxy cardaccount. The user 101 may perform this block by inputting identifyinginformation for each financial payment instrument account.

In an example embodiment, one or more financial instrument account(s)are maintained by the proxy card system 140 and other payment instrumentsystems 170. In an alternative example embodiment, the proxy card system140 maintains one or more of the financial instrument accounts and actsas the issuer for that financial instrument account. In another exampleembodiment, the financial instrument accounts are maintained by morethan one payment instrument systems 170, including the proxy card system140.

In block 220, the user 101 establishes rules for selecting a paymentinstrument in a transaction. The user 101 can use that proxy cardapplication 115 on the user device 110, a website on the web server 141of the proxy card system 140, or any suitable hardware or softwareapplications to establish rules. The user 101 can select from aselection of rules supplied by the proxy card system 140 or the user 101can input new rules.

Additionally or alternatively, the proxy card system 140 can establishrules for selecting a payment instrument in a transaction and makerecommendations to the user 101. For example, the proxy card system 140can establish default payment instruments, make recommendations based onthe rules of other users, make a recommendation based on paymentinstrument benefits or fees, or establish any other suitable rule orrecommendation.

In an example of a rule that can be established by the proxy card system140 or by the user 101, a particular payment instrument may bedesignated as the payment instrument to be selected for an identifiedmerchant category codes (“MCC”) or a group of codes. In another example,a payment instrument may be designated as the payment instrument to beselected for an identified merchant. In another example, proxy cardsystem 140 may be directed to select the payment instrument with thelowest balance or the most available credit. Any other suitable rule canbe established to select a payment instrument for a proposedtransaction.

In block 225, the proxy card system 140 sends the user proxy cardaccount identification information to the card network (not shown). ThePOS terminal 134 can identify the account number as belonging to a proxycard account on the proxy card system 140. Alternatively, theidentification of the proxy card and the proxy card system 140 can occurat any place in the system of merchant system 130, acquirer, cardnetwork, or payment instrument system 170.

In block 230, the card network stores the proxy card accountidentification information. In an alternative example embodiment, theaccount number identifies the proxy card system 140 as the issuer andpayments are automatically routed from the card network to the proxycard system 140 for approval.

In alternate embodiments of the invention, the proxy card account can beconfigured through any other process. For example, the proxy card may behidden from the user 101. The user 101 may configure an account with theproxy card system 140 and have a proxy card automatically installed onthe account for use with the user device 110 or other device. Theaccount may be linked to a financial account or other account of theuser 101. The user 101 may choose one financial account to be the activeaccount and the selected financial account can become the backinginstrument for the proxy card.

In another example, the method 200 can perform block 210 after blocks220 and 230 are performed. That is, the user 101 can create a proxy cardsystem 140 account and associate one or more financial accounts with theproxy card system 140 account. The proxy card system 140 may then issuea proxy card and associate the proxy card with the account of the user101.

FIG. 3 is a block flow diagram depicting a method 300 for associatingtransaction IDs with a payment instrument, in accordance with certainexample embodiments.

In block 305, a proxy card purchase request is received by the proxycard system 140. The proxy card is used to conduct a transaction with amerchant system 130. The merchant system 130 can be at a physicalmerchant location or an online merchant location. The user 101 canselect one or more products for purchase and initiate a transaction withthe proxy card. As previously described, the initiation can be via aphysical proxy card, contactless transaction with a user device, or anonline transaction.

In block 310, the proxy card system 140 receives the transaction ID inthe transaction details in the transaction request from the merchantsystem 130. Additionally or alternatively, the transaction ID may betransmitted separate from the transaction request. Additionally oralternatively, the transaction ID may be obtained from another sourceother than the merchant system 130, such as the user device 110, a thirdparty server, or other suitable entity.

In block 315, the proxy card system 140 identifies the paymentinstrument to use based on the MCC or other rules. Any rule establishedby the user or the proxy card system 140 can dictate the paymentinstrument to be used. Alternatively, the user 101 selects the paymentinstrument for use in the transaction. The user 101 can make a selectionby actuating a physical or virtual button, by a voice command, bytapping the appropriate representation of the payment instrument, or byany other suitable manner of selecting an instrument. After a selectionis made by the user 101, the selected payment instrument can bedisplayed on the user device 110.

In an alternate example embodiment, the proxy card system 115 canconduct the transaction without the selection of a payment instrument.At a time after the transaction is conducted, or at any time during thetransaction, the payment instrument can be selected. The selection canbe based on a set of rules as described above or can be made by the user101 of the proxy card system 140.

In block 320, the proxy card system 140 creates a second payment requestand forwards the request to the payment instrument system 170 thatissued the payment instrument designated as the backing instrument forthe transaction.

In block 325, the proxy card system 140 stores the transaction ID in adatabase of transaction IDs and associates an identification of thepayment instrument that is used for the identified transaction.Additionally or alternatively, the proxy card system 140 can associatethe transaction ID and the employed payment instrument in a transactionrecord database of the proxy card system 140. Additionally oralternatively, the proxy card system 140 can store the transaction IDand the employed payment instrument in an account of the user 101 on theproxy card system 140. The proxy card system 140 can associate and storethe transaction ID and the utilized payment instrument in any manner orlocation available to the proxy card system 140 that will allow thetransaction ID and the utilized payment to be retrieved at the time of arefund or any other suitable time.

In block 330, the payment instrument system 170 authorizes thetransaction. The payment instrument system 170 can employ the sameauthorization methodology that is employed on a standard transactionusing the payment instrument. For example, if the payment instrument isa credit card, the payment instrument system can determine if the creditcard has available credit sufficient to fund the transaction, determineif the transaction appears to be non-fraudulent, and follow any othersuitable steps for authorization. In another example, a stored valuecard can determine if sufficient funds are stored on the card to fundthe transaction. Any other suitable authorization process can beemployed. The payment instrument system 170 can transmit theauthorization to the proxy card system 140.

In block 335, after receiving the authorization from the paymentinstrument system 170, the proxy card system 140 can authorize thetransaction and transmit the authorization to the merchant system 130through the card network system or through any other suitable system. Ifthe payment instrument system 170 does not authorize the transaction,the proxy card system 140 can transmit a notice to the merchant system130 that the transaction is declined. In an alternate embodiment, theproxy card system 140 can attempt the transaction with an alternatepayment instrument.

In block 340, the transaction is completed at the merchant system 130.For example, after receiving the authorization from the proxy cardsystem 140, the merchant system 130 can deliver the product or serviceto the user 101, provide a receipt to the user 101, receive a signatureof the user 101, or perform any other suitable tasks to complete thetransaction.

FIG. 4 is a block flow diagram depicting a method 400 for matchingrefunds to the appropriate payment instrument employed in a proxy cardtransaction, in accordance with certain example embodiments.

In block 405, a user 101 presents a real or virtual proxy card to amerchant system 130 to obtain a refund for a previous transaction. Thepresentation may be in person at a merchant system 130 location.Additionally or alternatively, the presentation may be made on anInternet connection with the merchant system 130 over the network 105,over a telephone call, or in any other suitable manner. The user 101 canrequest the refund for a defective product, an erroneous or fraudulentcharge, poor service, or any suitable reason for a refund.

In block 410, the merchant system 130 issues a refund authorization andtransmits the authorization to the proxy card system 140. The proxy cardsystem 140 receives the refund authorization and the transaction ID. Therefund authorization can be transmitted to the proxy card system 140 viaan Internet connection over the network 105, via text, via email, or anysuitable communication method. The authorization can be textauthorization, a code based on a preconfigured refund system, or anysuitable authorization format available to the merchant system 130 andthe proxy card system 140. If the refund authorization does not containa transaction ID, the proxy card system 140 can request the transactionID from the merchant system 130.

In block 415, the proxy card system 140 identifies the transaction IDfor use in identifying the record of the transaction and the associatedpayment instrument.

In block 420, the proxy card system 140 identifies the paymentinstrument associated with the transaction ID. The proxy card system 140can cross-reference databases containing the stored transaction IDs andthe payment instruments. The proxy card system 140 can locate thepayment instrument in a database that has the transaction IDs and theassociated payment instruments. The proxy card system 140 can determinethe payment instrument by searching any suitable system employed tomatch the transaction IDs and the associated payment instruments.

In block 425, the proxy card system 140 creates a second refundauthorization and transmits the authorization to the payment instrumentsystem 170 that issued the payment instrument associated with thetransaction. The second refund authorization can be transmitted to thepayment instrument system 170 via an Internet connection over thenetwork 105, via text, via email, or any suitable communication method.The authorization can be text authorization, a code based on apreconfigured refund system, or any suitable authorization formatavailable to the proxy card system 140 and the payment instrument system170.

In block 430, the payment instrument system 170 accepts the refundtransaction. The acceptance may be automatic or approved by an operatorof the payment instrument system 170. Additionally or alternatively, theacceptance may be made by an automated process or other suitableprocess.

In block 435, the user 101 receives the confirmation of the completionof the refund from the payment instrument system 170. In an alternateembodiment the payment instrument system 170 can inform the proxy cardsystem 140 of the refund completion and request that the proxy cardsystem 140 inform the user 101. The user 101 can receive a notice of therefund on a website of the proxy card system 140, a website of thepayment instrument system 170, via a text or email, or through anysuitable communication method.

In an alternate embodiment, the refund may be prompted by a chargeback.The chargeback may be initiated by the proxy card system 140, thepayment instrument system 170, or another suitable entity. Thechargeback may be due to a fraudulent charge, an erroneous charge, orany other suitable reason. The identification of the transaction ID andthe associated payment instrument may follow a similar process as astandard refund authorization.

In an alternate embodiment, the proxy card system 140 can pass therefund to payment instrument system 170 regardless of whether thepayment instrument is active, deactivated, deleted, disabled, orpartially disabled from the proxy card account of the user 101.

In an alternate embodiment, the proxy card system 140 retains the refundin the user account. The proxy card system 140 can associate the refundwith the payment instrument used in the original transaction and applythe refund to future transactions using the payment instrument as thebacking instrument in a proxy card purchase. Alternatively, the proxycard system 140 can use the retained refund for any purchase involvingthe proxy card account of the user.

Example Systems

FIG. 5 depicts a computing machine 2000 and a module 2050 in accordancewith certain example embodiments. The computing machine 2000 maycorrespond to any of the various computers, servers, mobile devices,embedded systems, or computing systems presented herein. The module 2050may comprise one or more hardware or software elements configured tofacilitate the computing machine 2000 in performing the various methodsand processing functions presented herein. The computing machine 2000may include various internal or attached components such as a processor2010, system bus 2020, system memory 2030, storage media 2040,input/output interface 2060, and a network interface 2070 forcommunicating with a network 2080.

The computing machine 2000 may be implemented as a conventional computersystem, an embedded controller, a laptop, a server, a mobile device, asmartphone, a set-top box, a kiosk, a vehicular information system, onemore processors associated with a television, a customized machine, anyother hardware platform, or any combination or multiplicity thereof. Thecomputing machine 2000 may be a distributed system configured tofunction using multiple computing machines interconnected via a datanetwork or bus system.

The processor 2010 may be configured to execute code or instructions toperform the operations and functionality described herein, managerequest flow and address mappings, and to perform calculations andgenerate commands. The processor 2010 may be configured to monitor andcontrol the operation of the components in the computing machine 2000.The processor 2010 may be a general purpose processor, a processor core,a multiprocessor, a reconfigurable processor, a microcontroller, adigital signal processor (“DSP”), an application specific integratedcircuit (“ASIC”), a graphics processing unit (“GPU”), a fieldprogrammable gate array (“FPGA”), a programmable logic device (“PLD”), acontroller, a state machine, gated logic, discrete hardware components,any other processing unit, or any combination or multiplicity thereof.The processor 2010 may be a single processing unit, multiple processingunits, a single processing core, multiple processing cores, specialpurpose processing cores, co-processors, or any combination thereof.According to certain embodiments, the processor 2010 along with othercomponents of the computing machine 2000 may be a virtualized computingmachine executing within one or more other computing machines.

The system memory 2030 may include non-volatile memories such asread-only memory (“ROM”), programmable read-only memory (“PROM”),erasable programmable read-only memory (“EPROM”), flash memory, or anyother device capable of storing program instructions or data with orwithout applied power. The system memory 2030 may also include volatilememories such as random access memory (“RAM”), static random accessmemory (“SRAM”), dynamic random access memory (“DRAM”), synchronousdynamic random access memory (“SDRAM”). Other types of RAM also may beused to implement the system memory 2030. The system memory 2030 may beimplemented using a single memory module or multiple memory modules.While the system memory 2030 is depicted as being part of the computingmachine 2000, one skilled in the art will recognize that the systemmemory 2030 may be separate from the computing machine 2000 withoutdeparting from the scope of the subject technology. It should also beappreciated that the system memory 2030 may include, or operate inconjunction with, a non-volatile storage device such as the storagemedia 2040.

The storage media 2040 may include a hard disk, a floppy disk, a compactdisc read only memory (“CD-ROM”), a digital versatile disc (“DVD”), aBlu-ray disc, a magnetic tape, a flash memory, other non-volatile memorydevice, a solid sate drive (“SSD”), any magnetic storage device, anyoptical storage device, any electrical storage device, any semiconductorstorage device, any physical-based storage device, any other datastorage device, or any combination or multiplicity thereof. The storagemedia 2040 may store one or more operating systems, application programsand program modules such as module 2050, data, or any other information.The storage media 2040 may be part of, or connected to, the computingmachine 2000. The storage media 2040 may also be part of one or moreother computing machines that are in communication with the computingmachine 2000 such as servers, database servers, cloud storage, networkattached storage, and so forth.

The module 2050 may comprise one or more hardware or software elementsconfigured to facilitate the computing machine 2000 with performing thevarious methods and processing functions presented herein. The module2050 may include one or more sequences of instructions stored assoftware or firmware in association with the system memory 2030, thestorage media 2040, or both. The storage media 2040 may thereforerepresent examples of machine or computer readable media on whichinstructions or code may be stored for execution by the processor 2010.Machine or computer readable media may generally refer to any medium ormedia used to provide instructions to the processor 2010. Such machineor computer readable media associated with the module 2050 may comprisea computer software product. It should be appreciated that a computersoftware product comprising the module 2050 may also be associated withone or more processes or methods for delivering the module 2050 to thecomputing machine 2000 via the network 2080, any signal-bearing medium,or any other communication or delivery technology. The module 2050 mayalso comprise hardware circuits or information for configuring hardwarecircuits such as microcode or configuration information for an FPGA orother PLD.

The input/output (“I/O”) interface 2060 may be configured to couple toone or more external devices, to receive data from the one or moreexternal devices, and to send data to the one or more external devices.Such external devices along with the various internal devices may alsobe known as peripheral devices. The I/O interface 2060 may include bothelectrical and physical connections for operably coupling the variousperipheral devices to the computing machine 2000 or the processor 2010.The I/O interface 2060 may be configured to communicate data, addresses,and control signals between the peripheral devices, the computingmachine 2000, or the processor 2010. The I/O interface 2060 may beconfigured to implement any standard interface, such as small computersystem interface (“SCSI”), serial-attached SCSI (“SAS”), fiber channel,peripheral component interconnect (“PCI”), PCI express (PCIe), serialbus, parallel bus, advanced technology attached (“ATA”), serial ATA(“SATA”), universal serial bus (“USB”), Thunderbolt, FireWire, variousvideo buses, and the like. The I/O interface 2060 may be configured toimplement only one interface or bus technology. Alternatively, the I/Ointerface 2060 may be configured to implement multiple interfaces or bustechnologies. The I/O interface 2060 may be configured as part of, allof, or to operate in conjunction with, the system bus 2020. The I/Ointerface 2060 may include one or more buffers for bufferingtransmissions between one or more external devices, internal devices,the computing machine 2000, or the processor 2010.

The I/O interface 2060 may couple the computing machine 2000 to variousinput devices including mice, touch-screens, scanners, biometricreaders, electronic digitizers, sensors, receivers, touchpads,trackballs, cameras, microphones, keyboards, any other pointing devices,or any combinations thereof. The I/O interface 2060 may couple thecomputing machine 2000 to various output devices including videodisplays, speakers, printers, projectors, tactile feedback devices,automation control, robotic components, actuators, motors, fans,solenoids, valves, pumps, transmitters, signal emitters, lights, and soforth.

The computing machine 2000 may operate in a networked environment usinglogical connections through the network interface 2070 to one or moreother systems or computing machines across the network 2080. The network2080 may include wide area networks (WAN), local area networks (LAN),intranets, the Internet, wireless access networks, wired networks,mobile networks, telephone networks, optical networks, or combinationsthereof. The network 2080 may be packet switched, circuit switched, ofany topology, and may use any communication protocol. Communicationlinks within the network 2080 may involve various digital or an analogcommunication media such as fiber optic cables, free-space optics,waveguides, electrical conductors, wireless links, antennas,radio-frequency communications, and so forth.

The processor 2010 may be connected to the other elements of thecomputing machine 2000 or the various peripherals discussed hereinthrough the system bus 2020. It should be appreciated that the systembus 2020 may be within the processor 2010, outside the processor 2010,or both. According to some embodiments, any of the processor 2010, theother elements of the computing machine 2000, or the various peripheralsdiscussed herein may be integrated into a single device such as a systemon chip (“SOC”), system on package (“SOP”), or ASIC device.

In situations in which the systems discussed here collect personalinformation about users, or may make use of personal information, theusers may be provided with a opportunity to control whether programs orfeatures collect user information (e.g., information about a user'ssocial network, social actions or activities, profession, a user'spreferences, or a user's current location), or to control whether and/orhow to receive content from the content server that may be more relevantto the user. In addition, certain data may be treated in one or moreways before it is stored or used, so that personally identifiableinformation is removed. For example, a user's identity may be treated sothat no personally identifiable information can be determined for theuser, or a user's geographic location may be generalized where locationinformation is obtained (such as to a city, ZIP code, or state level),so that a particular location of a user cannot be determined. Thus, theuser may have control over how information is collected about the userand used by a content server.

Embodiments may comprise a computer program that embodies the functionsdescribed and illustrated herein, wherein the computer program isimplemented in a computer system that comprises instructions stored in amachine-readable medium and a processor that executes the instructions.However, it should be apparent that there could be many different waysof implementing embodiments in computer programming, and the embodimentsshould not be construed as limited to any one set of computer programinstructions. Further, a skilled programmer would be able to write sucha computer program to implement an embodiment of the disclosedembodiments based on the appended flow charts and associated descriptionin the application text. Therefore, disclosure of a particular set ofprogram code instructions is not considered necessary for an adequateunderstanding of how to make and use embodiments. Further, those skilledin the art will appreciate that one or more aspects of embodimentsdescribed herein may be performed by hardware, software, or acombination thereof, as may be embodied in one or more computingsystems. Moreover, any reference to an act being performed by a computershould not be construed as being performed by a single computer as morethan one computer may perform the act.

The example embodiments described herein can be used with computerhardware and software that perform the methods and processing functionsdescribed previously. The systems, methods, and procedures describedherein can be embodied in a programmable computer, computer-executablesoftware, or digital circuitry. The software can be stored oncomputer-readable media. For example, computer-readable media caninclude a floppy disk, RAM, ROM, hard disk, removable media, flashmemory, memory stick, optical media, magneto-optical media, CD-ROM, etc.Digital circuitry can include integrated circuits, gate arrays, buildingblock logic, field programmable gate arrays (FPGA), etc.

The example systems, methods, and acts described in the embodimentspresented previously are illustrative, and, in alternative embodiments,certain acts can be performed in a different order, in parallel with oneanother, omitted entirely, and/or combined between different exampleembodiments, and/or certain additional acts can be performed, withoutdeparting from the scope and spirit of various embodiments. Accordingly,such alternative embodiments are included in the inventions claimedherein.

Although specific embodiments have been described above in detail, thedescription is merely for purposes of illustration. It should beappreciated, therefore, that many aspects described above are notintended as required or essential elements unless explicitly statedotherwise. Modifications of, and equivalent components or actscorresponding to, the disclosed aspects of the example embodiments, inaddition to those described above, can be made by a person of ordinaryskill in the art, having the benefit of the present disclosure, withoutdeparting from the spirit and scope of embodiments defined in thefollowing claims, the scope of which is to be accorded the broadestinterpretation so as to encompass such modifications and equivalentstructures.

1. A computer-implemented method to match refunds to paymentinstruments, comprising: receiving, using one or more computing devices,a first payment authorization request for a transaction between amerchant and a user, the payment authorization request comprising anidentification of a user proxy account and an identifier for thetransaction, the user proxy account having associated therewith aplurality of payment instruments available for conducting paymenttransactions; determining, using the one or more computing devices, aparticular payment instrument of the plurality of payment instrumentswith which to conduct the transaction; associating, using the one ormore computer devices, the transaction identifier with the particularone of the payment instruments utilized in the transaction;communicating, using the one or more computing devices, a second paymentauthorization request to a computing system associated with an issuer ofthe particular payment instrument, requesting authorization to fund thetransaction using the particular payment instrument; receiving, usingthe one or more computing devices, a first payment authorization fromthe computing system associated with the issuer of the particularpayment instrument, authorizing funding of the transaction using theparticular payment instrument; communicating, using the one or morecomputing devices, a second payment authorization authorizing funding ofthe first payment authorization request based at least in part on thefirst payment authorization; receiving, using the one or more computingdevices, a first refund instruction to refund at least a portion of apayment amount of the transaction, the first refund instructioncomprising the transaction identifier; determining, using the one ormore computer devices, the particular payment instrument associated withthe transaction identifier provided in the first refund instruction; andinitiating, using the one or more computing devices, the refund to theparticular payment instrument that is determined as being associatedwith the transaction identifier.
 2. The computer-implemented method ofclaim 1, wherein the initiating step comprises communicating, using theone or more computing devices, a second refund instruction to thecomputing system associated with the issuer of the particular paymentinstrument to refund or a portion of the payment amount of thetransaction.
 3. The computer-implemented method of claim 1, wherein theinitiating step comprises retaining, using the one or more computingdevices, all or a portion of the payment amount of the transaction forcredit against a future transaction involving the particular paymentinstrument.
 4. The computer-implemented method of claim 1, furthercomprising providing, using the one or more computing devices, a noticeto the user of the refund.
 5. The computer-implemented method of claim1, wherein the associating step comprises storing the transactionidentifier and the associated payment instrument in a database.
 6. Thecomputer-implemented method of claim 1, wherein the determining stepcomprises: accessing, using the one or more computer devices, thetransaction identification in a database of the proxy card system; andidentifying, using the one or more computer devices, the paymentinstrument associated with the transaction identification.
 7. Thecomputer-implemented method of claim 1, wherein the first refundinstruction is initiated by a chargeback from the issuer of theparticular payment instrument.
 8. The computer-implemented method ofclaim 1, wherein the first refund instruction is initiated by achargeback from the one or more computing devices.
 9. Thecomputer-implemented method of claim 1, wherein the first refundinstruction is initiated by the merchant.
 10. A computer programproduct, comprising: a non-transitory computer-readable storage devicehaving computer-readable program instructions embodied thereon that whenexecuted by a computer perform a method to match refunds to paymentaccounts, the computer-readable program instructions comprising:computer program instructions to receive, a first payment authorizationrequest for a transaction between a merchant and a user, the paymentauthorization request comprising an identification of an account of theuser and an identifier for the transaction, the user account havingassociated therewith a plurality of payment accounts available forconducting payment transactions; computer program instructions todetermine a particular payment account of the plurality of paymentaccounts with which to conduct the transaction; computer programinstructions to associate the transaction identifier with the particularone of the payment accounts utilized in the transaction; computerprogram instructions to communicate a second payment authorizationrequest to a computing system associated with an issuer of theparticular payment account, requesting authorization to fund thetransaction using the particular payment account; computer programinstructions to receive a first payment authorization from the computingsystem associated with the issuer of the particular payment account,authorizing funding of the transaction using the particular paymentaccount; computer program instructions to communicate a second paymentauthorization authorizing funding of the first payment authorizationrequest based at least in part on the first payment authorization;computer program instructions to receive a first refund instruction torefund at least a portion of a payment amount of the transaction, thefirst refund instruction comprising the transaction identifier; computerprogram instructions to determine the particular payment accountassociated with the transaction identifier provided in the first refundinstruction; and computer program instructions to communicate initiatethe refund to the particular payment account that is determined as beingassociated with the transaction identifier.
 11. The computer programproduct of claim 10, wherein initiating the refund comprisescommunicating, using the one or more computing devices, a second refundinstruction to the computing system associated with the issuer of theparticular payment account to refund all or a portion of the paymentamount of the transaction.
 12. The computer program product of claim 10,wherein the initiating the refund comprises retaining all or a portionof the payment amount of the transaction for credit against a futuretransaction involving the particular payment account.
 13. The computerprogram product of claim 10, the computer-readable program instructionsfurther comprising computer program instructions to provide a notice tothe user of the refund.
 14. The computer program product of claim 10,wherein the associating the transaction identifier comprises storing thetransaction identifier and the associated payment instrument in adatabase.
 15. A system to use a one-time code to match refunds topayment instruments, the system comprising: a storage device; a networkdevice; and a processor communicatively coupled to the storage deviceand the network device, wherein the processor executes application codeinstructions that are stored in the storage device and that cause thesystem to: receive a first payment authorization request for atransaction between a merchant and a user, the payment authorizationrequest comprising an identification of a user account and an identifierfor the transaction, the user account having associated therewith aplurality of payment instruments available for conducting paymenttransactions; determine a particular payment instrument of the pluralityof payment instruments with which to conduct the transaction; associatethe transaction identifier with the particular one of the paymentinstruments utilized in the transaction; receive a first refundinstruction to refund at least a portion of a payment amount of thetransaction, the first refund instruction comprising the transactionidentifier; determine the particular payment instrument associated withthe transaction identifier provided in the first refund instruction; andinitiate the refund to the particular payment instrument that isdetermined as being associated with the transaction identifier.
 16. Thesystem of claim 15, the processor executing further application codeinstructions that are stored in the storage device and that cause thesystem to: communicate a second payment authorization request to acomputing system associated with an issuer of the particular paymentinstrument, requesting authorization to fund the transaction using theparticular payment instrument; receive a first payment authorizationfrom the computing system associated with the issuer of the particularpayment instrument, authorizing funding of the transaction using theparticular payment instrument; communicate a second paymentauthorization authorizing funding of the first payment authorizationrequest based at least in part on the first payment authorization; 17.The system of claim 15, wherein the first refund instruction isinitiated by a chargeback from the issuer of the particular paymentinstrument.
 18. The system of claim 15, wherein the first refundinstruction is initiated by a chargeback from the one or more computingdevices.
 19. The system of claim 15, wherein the first refundinstruction is initiated by the merchant.
 20. The system of claim 15,wherein initiating the refund comprises instructions to communicate asecond refund instruction to the computing system associated with theissuer of the particular payment instrument to refund all or a portionof the payment amount of the transaction.